This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
"You can call agents on docs in 8.5.0 and 8.5.1, though this means you have to save the doc prior to processing. "
- True, this is possible. But my experience doing this shows it has a number of serious flaws:
1. One must save the document first. This is a whole can of worms, some my doing and some not.
a. In my instance I wind up committing data to the database that's invalid, because my validation logic is in LotusScript classes. Some of that logic could be put in JS, but some of it is impossible to put into JS without scrapping the entire system. So I commit invalid data and flag it as such in the Agent, because I have no choice.
b. It seems that saving the XPage document demands concurrencyMode=force if the LS Agent is going to attempt to actually commit data. Since I've never written an Agent (except LS to generate web pages) that does not commit data, this must be set or one gets save conflicts, even if the LS is coded save(true, true).
c. The above, (b), seems to cause a commit to fail if there aren't any changes to the document. Since LS has no way to know if anything has actually changed (no NotesDocument.isDirty, for instance), the normal way to do things is - when in doubt - save anyway. But if one does that from an XPage then
if(not doc.save(true, true)) then complain
will in fact complain, causing the code to fail. Every time. So I get to manually manage "dirtiness" to get code that's been working for years to keep working.
2. Once the Agent is done running, the SSJS on the XPage has no ready access to the results, as fields on currentDocument reflect the *old* values before the Agent ran. Deleting currentDocument has no effect. I surmise the XSP command processor keeps an in-memory copy during the Agent's execution, that it never bothers to refresh, which Is Not Good.
3. It seems having an Agent process code using LS2J when called from postSaveDocument on an XPage causes all manner of weirdness. The only way to fix this was to commit text describing the desired operation to a sessionScope variable, along with parameter data, then close the XPage and have the next page loaded check sessionScope, then process it using AJAX. LS2J is legacy code ... if legacy code is supported in an Agent from an XPage then this shouldn't be happening. Instead XPage + LS2J = nightmare.
4. The postSaveDocument event randomly fails to fire, so the XPages where a LS Agent actually can do something without freaking out, random doesn't do anything. To be more freakish, the querySaveDocument event does run, and even though that event does nothing what-so-ever but log that fact, pSD never goes off. i have never seen it function reliably over months, though it's possible once one stops rebuilding the application constantly it will in fact work reliably. But during development ... uh uh.
- Do not drink the legacy migration XPage Kool-Aid.
Feedback response number DGIE85SSLK created by ~Holly Zekhipisonnivu on 05/25/2010
It is as bad as you think...
Return to top
. . . . It is as bad as you think... (~James Brewever... 25.May.10) 
